In a traditional network including printers, a print server is connected to one or more physical printers and one or more print clients. Typically, these client computers send information to be printed in the form of a document, called a print job, encoded in some intermediate data format to the print server along with information regarding which printer should be used. When the print server receives the print job and printer information, it routes the job to the appropriate print queue associated with the chosen printer. As the server prints jobs from the queue to the attached printer, it interprets and translates the print jobs using stored information regarding the printer, including administrative settings, printer settings and the printer driver. The print server then renders the print jobs from the transferred intermediate data format to a native printer language and sends them to the printer. The process of rendering is simply this translation from some intermediate data format to the final printer-specific format that can be sent directly to the printer.
This thin client and robust server technology has a number of associated problems. The most significant problem with this resource-intensive server side rendering is the difficulty in scaling server networks. Since clients provide little print functionality, off-loading these tasks instead to the server, the number of actively printing clients connected to a print server must be strictly limited to avoid overloading the server. Another difficulty is inherent in applying administrative and printer settings once the print job has reached the server without informing the client. If the client is unaware of which administrative settings are in effect, the actual print output may be unexpected. Yet another shortcoming of typical print networks arises in those cases in which a client sends a print job in an intermediate data format specified by the particular printer's driver. If, for some reason, the printer drivers stored by the server and client are different, the server's translation of this intermediate data format might fail, yielding poor printing performance. Finally, since print jobs are queued solely on the server, server side rendering discourages offline printing. In a typical print network, when a server goes offline, a client is not only unable to use a printer connected to that server, but also will not queue documents for that offline printer. Thus, the responsibility falls on the user of the client to print a particular document when the server becomes available once again.
Some print network implementations have solved some but not all of the problems described above. So, for example, client side rendering has been supported in some print networks. In a client side rendering implementation, the print server routes print jobs to the appropriate printers, but the client performs the rendering of a document in the intermediate data format to the native printer language. While clients are able to pass this printer-formatted document to the print server, the problem remains that the client's intended formatting may not correctly apply the administrative settings stored on the server. In addition, off-line rendering of the document by the client might violate administrative mandates and so is often not enabled.
In other print networks, administrative settings are communicated to the client, but the client is unable to render the document and instead sends the intermediate data format to the print server for rendering. In these networks, many of the problems described in the preceding paragraphs remain. Print server scaling remains nearly impossible in these networks as the servers are still burdened with the task of rendering documents, and server and client print drivers must be assiduously matched.
As a result, there remains a need for a print network that supports offline printing, as an automated and transparent printing solution.